CM re:Growth 2014 TOKYOで運用目線でAWSって素晴らしいって話をしてきた #cmdevio

あのときAWS環境だったら…

[slideshare id=42781104&doc=devio-mtup11-tokyo-012-141216220210-conversion-gate01]

内容

物理サーバでの対応とAWSでの対応の違いについて運用目線で話しました。

サーバ再起動のとき

• IDCにサーバを預けていた時はサーバ再起動に時間がかかっていた。
  • 障害受付センターへ電話→現地作業員からの折り返し待ち
• AWSだと
  • マネージメントコンソールに入ってstop→start

サービスへの影響時間も減少しました。

DISK容量が足りなくなってきたとき

• 物理サーバでDISK容量が足りなくなってくると大変だった。
  • とにかく不要ファイルを削除する
  • ログの保持期間を検討する
  • 外付けハードディスクをつける
  • リプレース
• AWSだと
  • EBSでDISKの追加と拡張

DISK容量問題もAWSだと簡単に対応可能ですね。

スペックが不足したとき

運用していて、サーバのスペックが足りなくなってくるときってありますよね。

• 物理サーバだと
  • とにかくミドルウェアのチューニング
  • スペックの高いサーバに移設(時間かかる)
  • 負荷分散(時間かかる)
• AWSだと
  • スケールアップ(インスタンスタイプ変更)
  • スケールアウト(AMI取得して負荷分散)

スペックが不足してきた時の対応も柔軟にできます。

アクセスが増えたとき

アクセスが増えるって嬉しいことですが、すぐにサーバを用意できない経験をしたこともあると思います。

• 物理だと
  • 負荷分散するためにサーバを用意
  • サーバスペックあげるためにリプレース
• AWSだと
  • ELB + EC2 で負荷分散
  • スペックアップ(インスタンスタイプ変更)

負荷分散もスペックアップも即時対応できますね。

バックアップ

バックアップって必要ですよね。

• 物理だと
  • バックアップサーバを用意
  • rsync, tar, dar, dumpなどのバックアップツールを選定
  • mount, scp, mv, ftpなどのデータ転送方法選定
• AWSだと
  • スナップショット！

バックアップってrsync, tar, dar, dumpなどのバックアップツールを選定し バックアップサーバにどうやってデータを送るかを考えますがこちらもDISK容量が気になってきたり、 複数のツールを使っていると復旧の手順が煩雑化したりしますが AWSのスナップショットだとS3に保存されるので容量も気にせず、耐久性も心配ありません。 タグをつけて世代管理も簡単にできたり、復旧手順の一元化も可能です。

困った時

AWSサポートが優秀

• トラブルシューティングをしてくれる
• ベストプラクティスも教えてくれる
• サードパーティ製のソフトウェアのサポートも行ってくれる

ビジネス以上のサポートに入ると24時間、電話、メール、チャットでの対応もしてくれてとても安心。

まとめ

昔は物理サーバの環境が多かったので上記のような問題がありましたが AWS環境が増えていくにつれて柔軟・迅速に対応が行えるようになったと思います。 そして、AWSサポートは素晴らしいと思います。

さいごに